utils/passkeys/createPasskey.ts (2)

44-44: Use a more robust method for generating userId

Generating userId using Date.now() converted to base64 may lead to collisions if passkeys are created rapidly. Consider using a universally unique identifier (UUID) to ensure uniqueness.

Update the code to generate a UUID:

-  const userId = Buffer.from(String(Date.now())).toString("base64");
+  import { v4 as uuidv4 } from 'uuid';
+  const userId = Buffer.from(uuidv4()).toString("base64");

Ensure to install and import the uuid package.

---

77-79: Remove unnecessary null check for client

The client variable is instantiated just before the null check, so it cannot be null. The check if (!client) is unnecessary and can be removed to simplify the code.

Apply this diff:

     stamper
   );
-  if (!client) {
-    throw new Error("No client found");
-  }

utils/xmtpRN/signer.ts (1)

21-21: Consider extracting the chain ID comment to a constant.

This comment is duplicated from the ethersSignerToXmtpSigner function. Consider extracting it to a constant to maintain DRY principles.

+const CHAIN_ID_COMMENT = "// We don't really care about the chain id because we support https://eips.ethereum.org/EIPS/eip-6492";
+
 export const ethersSignerToXmtpSigner = (
   signer: ethers.Signer,
   isSCW?: boolean
 ): XmtpSigner => ({
   getAddress: () => signer.getAddress(),
-  getChainId: () => ethereum.id, // We don't really care about the chain id because we support https://eips.ethereum.org/EIPS/eip-6492
+  getChainId: () => ethereum.id, ${CHAIN_ID_COMMENT}
   getBlockNumber: () => undefined,
   walletType: () => (isSCW ? "SCW" : "EOA"),
   signMessage: (message: string) => signer.signMessage(message),
 });

 export const viemSignerToXmtpSigner = (
   signer: LocalAccount<any>
 ): XmtpSigner => ({
   getAddress: () => Promise.resolve(signer.address),
-  getChainId: () => ethereum.id, // We don't really care about the chain id because we support https://eips.ethereum.org/EIPS/eip-6492
+  getChainId: () => ethereum.id, ${CHAIN_ID_COMMENT}
   getBlockNumber: () => undefined,
   walletType: () => "SCW",
   signMessage: (message: string) => signer.signMessage({ message }),
 });

features/onboarding/passkey/passkeyAuthStore.tsx (2)

46-52: Optimize selector usage.

Consider memoizing the selector to prevent unnecessary re-renders.

+import { useMemo } from 'react';

 export function usePasskeyAuthStoreContext<T>(
   selector: (state: IPasskeyAuthStoreState) => T
 ): T {
   const store = useContext(PasskeyAuthStoreContext);
   if (!store) throw new Error("Missing PasskeyAuthStore.Provider in the tree");
-  return useStore(store, selector);
+  const memoizedSelector = useMemo(() => selector, [selector]);
+  return useStore(store, memoizedSelector);
 }

---

4-11: Add JSDoc documentation for types.

Consider adding documentation for the store props and state to improve maintainability.

+/**
+ * Props for the passkey authentication store
+ */
 type IPasskeyAuthStoreProps = {
   loading: boolean;
 };

+/**
+ * State and actions for the passkey authentication store
+ */
 type IPasskeyAuthStoreState = IPasskeyAuthStoreProps & {
   setLoading: (loading: boolean) => void;
   reset: () => void;
 };

screens/Onboarding/OnboardingPasskeyScreen.tsx (2)

65-65: Remove console.log statements.

Debug logging should be removed from production code or replaced with proper logging utilities.

-      console.log("dm", dm);
+      logger.debug("[Passkey] DM conversation created", { conversationId: dm.id });

Also applies to: 92-92

---

104-106: Improve error message presentation.

Consider using a proper error component with user-friendly messages and potentially an icon.

-        <Text preset="body" color="caution">
-          {error}
-        </Text>
+        <ErrorMessage
+          icon="warning"
+          message={formatErrorMessage(error)}
+          onRetry={handleRetry}
+        />

screens/Navigation/Navigation.tsx (1)

214-217: Add navigation options for consistency.

Other screens in the SignedOutNavigation group use shared navigation options. Consider applying the same options to maintain consistency.

 <NativeStack.Screen
   name="OnboardingPasskey"
   component={OnboardingPasskeyScreen}
+  options={{
+    ...authScreensSharedScreenOptions,
+  }}
 />

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

screens/NewAccount/NewAccountEphemeralScreen.tsx (1)

Line range hint 28-43: Implement secure key handling and improve error feedback

The current implementation has several security and UX concerns:

1. Private key remains in memory
2. Generic error handling
3. Limited loading state feedback

Consider implementing:

  const generateWallet = useCallback(async () => {
    setLoading(true);
    try {
      const signer = new Wallet(utils.randomPrivateKey());
+     const address = await signer.getAddress();
      await initXmtpClient({
        signer,
-       address: await signer.getAddress(),
+       address,
        isEphemeral: true,
      });
+     // Clear sensitive data from memory
+     signer.privateKey = null;
      if (isMissingConverseProfile()) {
        router.navigate("NewAccountUserProfile");
      } else {
        router.navigate("Chats");
      }
    } catch (error) {
      sentryTrackError(error);
+     Alert.alert(
+       "Account Creation Failed",
+       "Unable to create your account. Please try again."
+     );
    } finally {
      setLoading(false);
    }
  }, [setLoading, router]);

utils/passkeys/create-passkey.ts (2)

19-64: Refactor onPasskeyCreate for better maintainability

The onPasskeyCreate function handles multiple responsibilities, including UI updates, passkey creation, sub-organization creation, and Turnkey account creation. This makes the function lengthy and harder to read and maintain.

Consider breaking down the function into smaller, focused functions. For example:

• Extract status updates into a separate utility function.
• Separate the logic for passkey creation, sub-organization creation, and account creation into individual functions.
• Handle errors closer to where they may occur to improve error tracing.

This modular approach will enhance readability and make unit testing more straightforward.

---

86-88: Use template literals for string concatenation

Currently, string concatenation is used to build name and displayName, which can be less readable.

Improve readability by using template literals:

    name: passkeyName + " " + humanReadableDate,
    displayName: passkeyName + " " + humanReadableDate,
+   name: `${passkeyName} ${humanReadableDate}`,
+   displayName: `${passkeyName} ${humanReadableDate}`,

utils/passkeys/create-suborganization.ts (1)

1-1: Remove unused import of createPasskey

The createPasskey function is imported but not used in this file.

Apply this diff to remove the unused import:

-import { createPasskey } from "@turnkey/react-native-passkey-stamper";

utils/passkeys/turnkey-clients.ts (1)

3-3: Consider using a more robust state management solution

Using a global mutable object for client management could lead to race conditions and memory leaks. Consider:

1. Using a proper state management solution (e.g., Redux)
2. Implementing a cleanup mechanism for stale clients
3. Adding TTL (Time-To-Live) for cached clients

utils/passkeys/passkeys.interfaces.ts (2)

3-7: Add JSDoc documentation for TurnkeyStoreInfo

Consider adding comprehensive documentation for this type as it contains sensitive wallet information.

+/**
+ * Represents the essential information stored for a Turnkey wallet.
+ * @property subOrganizationId - The unique identifier for the sub-organization
+ * @property walletId - The unique identifier for the wallet
+ * @property address - The Ethereum address associated with the wallet
+ */
 export type TurnkeyStoreInfo = {
   subOrganizationId: string;
   walletId: string;
   address: string;
 };

---

9-16: Consider adding validation patterns for PasskeyState

The state type could benefit from stricter constraints and validation patterns.

+/**
+ * Represents the current state of a passkey authentication process.
+ */
 export type PasskeyState = {
   loading: boolean;
   error: string | null;
   statusString: string | null;
   account: LocalAccount | null;
   turnkeyInfo: TurnkeyStoreInfo | null;
-  previousPasskeyName: string | null;
+  previousPasskeyName: string | null;
+  // Add validation patterns
+  readonly validate: () => boolean;
 };

utils/passkeys/create-turnkey-account.ts (1)

30-35: Implement retry mechanism for account creation

Add a retry mechanism for the account creation API call to handle temporary failures.

+    const MAX_RETRIES = 3;
+    let retries = 0;
+    
+    while (retries < MAX_RETRIES) {
+      try {
         const account = await createAccount({
           client,
           organizationId: subOrganizationId,
           signWith: address,
           ethereumAddress: address,
         });
+        return account;
+      } catch (error) {
+        retries++;
+        if (retries === MAX_RETRIES) throw error;
+        await new Promise(resolve => setTimeout(resolve, 1000 * retries));
+      }
+    }
-    return account;

utils/passkeys/add-wallet-to-passkey.ts (1)

27-42: Enhance wallet creation parameters

The current implementation has several areas for improvement:

1. Wallet name uses only UUID without timestamp or meaningful prefix
2. No retry logic for API calls
3. Missing validation for account parameters

Consider implementing:

+ const MAX_RETRIES = 3;
+ const generateWalletName = () => `Wallet_${Date.now()}_${uuidv4()}`;
+ 
+ const createWalletWithRetry = async (client, params, retries = 0) => {
+   try {
+     return await client.createWallet(params);
+   } catch (e) {
+     if (retries < MAX_RETRIES && isRetryableError(e)) {
+       await delay(Math.pow(2, retries) * 1000);
+       return createWalletWithRetry(client, params, retries + 1);
+     }
+     throw e;
+   }
+ };

  const res = await createWalletWithRetry(client, {
    type: "ACTIVITY_TYPE_CREATE_WALLET",
    timestampMs: Date.now().toString(),
    organizationId: subOrgId,
    parameters: {
-     walletName: "Wallet " + uuidv4(),
+     walletName: generateWalletName(),
      accounts: [
        {
          curve: "CURVE_SECP256K1",
          pathFormat: "PATH_FORMAT_BIP32",
          path: "m/44'/60'/0'/0/0",
          addressFormat: "ADDRESS_FORMAT_ETHEREUM",
        },
      ],
    },
  });

components/Onboarding/init-xmtp-client.ts (1)

15-21: Group related imports and use named exports

The imports could be better organized for clarity and maintainability.

- import {
-   createXmtpClientFromSigner,
-   createXmtpClientFromViemAccount,
- } from "../../utils/xmtpRN/signIn";
- import { getXmtpClient } from "../../utils/xmtpRN/sync";
- import { Signer } from "ethers";
- import { LocalAccount } from "viem/accounts";
+ // External imports
+ import { Signer } from "ethers";
+ import { LocalAccount } from "viem/accounts";
+ 
+ // Internal imports
+ import { getXmtpClient } from "../../utils/xmtpRN/sync";
+ import {
+   createXmtpClientFromSigner,
+   createXmtpClientFromViemAccount,
+ } from "../../utils/xmtpRN/signIn";

features/onboarding/passkey/passkeyAuthStore.tsx (2)

58-59: Enhance error handling in setLoading

The setLoading implementation clears errors when loading starts but not when loading ends. This could hide important error states.

-    setLoading: (loading) =>
-      loading ? set({ loading, error: undefined }) : set({ loading: false }),
+    setLoading: (loading) => set({ loading }),

---

6-23: Export type definitions

Consider exporting the type definitions to allow external components to properly type their props and state.

-type IPasskeyAuthStoreProps = {
+export type IPasskeyAuthStoreProps = {
   // ...
 };

-type IPasskeyAuthStoreState = IPasskeyAuthStoreProps & {
+export type IPasskeyAuthStoreState = IPasskeyAuthStoreProps & {
   // ...
 };

screens/NewAccount/NewAccountPasskeyScreen.tsx (1)

173-203: Extract common functionality to reduce code duplication

The onboardWithPasskey method duplicates logic from createPasskey and createXmtpClientFromAccount. Consider extracting common functionality.

Consider creating a utility function to handle the common passkey creation and XMTP client initialization flow:

const handlePasskeyCreation = async (passkeyName: string) => {
  const account = await onPasskeyCreate({
    passkeyName,
    setStatusString,
    setPreviousPasskeyName,
    setTurnkeyInfo,
  });
  return account;
};

utils/xmtpRN/signIn.ts (1)

71-120: Enhance error handling and logging.

While the implementation is solid, consider these improvements:

1. Add more descriptive error message for inbox ID mismatch
2. Add debug logging for key operations like database operations

 if (client.inboxId !== inboxId) {
-    throw new Error("Inbox ids don't match");
+    throw new Error(`Inbox ID mismatch. Expected: ${inboxId}, Got: ${client.inboxId}`);
 }

 logger.debug("Instantiating client from signer");
+logger.debug(`Using temporary directory: ${tempDirectory}`);
+logger.debug(`Processing inbox ID: ${inboxId}`);

 const installationValid = await isClientInstallationValid(client);
 if (!installationValid) {
+  logger.debug(`Installation invalid for inbox ID: ${inboxId}, cleaning up...`);
   await client.dropLocalDatabaseConnection();
   await deleteLibXmtpDatabaseForInboxId(inboxId);
   onInstallationRevoked();
   return;
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

screens/NewAccount/NewAccountConnectWalletScreen.tsx (1)

Line range hint 26-28: Add missing dependency to useCallback

The empty dependency array causes isMissingConverseProfile result to be stale, which could lead to incorrect navigation decisions.

    },
-     // eslint-disable-next-line react-hooks/exhaustive-deps
-     []
+     [router]
    );

screens/NewAccount/NewAccountPrivateKeyScreen.tsx (1)

Line range hint 28-31: Add private key format validation

The current implementation only checks if the private key is empty. Consider adding proper format validation to prevent runtime errors.

    try {
      const trimmedPrivateKey = privateKey.trim();
      if (!trimmedPrivateKey) return;
+     // Private keys are typically 64 characters (32 bytes) in hex format
+     if (!/^[0-9a-fA-F]{64}$/.test(trimmedPrivateKey)) {
+       throw new Error('Invalid private key format');
+     }
      await loginWithPrivateKey(trimmedPrivateKey);

utils/passkeys/create-suborganization.ts (1)

4-9: 🛠️ Refactor suggestion

Add error handling and improve type safety.

The function needs error handling and would benefit from explicit return type definition.

+type SubOrganizationResponse = {
+  subOrganizationId: string;
+  walletId: string;
+  address: string;
+};
+
 export async function createSubOrganization(
   authenticatorParams: Awaited<ReturnType<typeof createPasskey>>
-) {
-  const res = await createTurnkeySubOrganization(authenticatorParams);
+): Promise<SubOrganizationResponse> {
+  try {
+    const res = await createTurnkeySubOrganization(authenticatorParams);
+    return res;
+  } catch (error) {
+    console.error("Failed to create sub-organization", error);
+    throw error;
+  }
+}

utils/api.ts (1)

830-847: 🛠️ Refactor suggestion

Add error handling for wallet creation.

The function should handle potential errors during wallet creation and provide meaningful error messages.

 export const createTurnkeySubOrganization = async (
   authenticatorParams: TurnkeyAuthenticatorParams
 ): Promise<{
   subOrganizationId: string;
   walletId: string;
   address: string;
 }> => {
+  try {
     const { data } = await api.post(
       "/api/wallet/create-wallet-turnkey",
       {
         authenticatorParams,
       },
       {
         headers: await getAppCheckTokenHeaders(),
       }
     );
     return data;
+  } catch (error) {
+    logger.error("[API] Failed to create Turnkey wallet", error);
+    throw new Error(
+      error instanceof Error
+        ? error.message
+        : "Failed to create wallet. Please try again."
+    );
+  }
 };

utils/xmtpRN/signer.ts (1)

17-25: 🛠️ Refactor suggestion

Add isSCW parameter to maintain consistency with ethers implementation

The viemAccountToXmtpSigner function assumes all Viem LocalAccounts are Smart Contract Wallets (SCW), which is inconsistent with the ethersSignerToXmtpSigner implementation that supports both SCW and EOA wallet types through an isSCW parameter.

Apply this diff to maintain consistency:

-export const viemAccountToXmtpSigner = (
-  account: LocalAccount<any>
-): XmtpSigner => ({
+export const viemAccountToXmtpSigner = (
+  account: LocalAccount<any>,
+  isSCW?: boolean
+): XmtpSigner => ({
   getAddress: () => Promise.resolve(account.address),
   getChainId: () => ethereum.id,
   getBlockNumber: () => undefined,
-  walletType: () => "SCW",
+  walletType: () => (isSCW ? "SCW" : "EOA"),
   signMessage: (message: string) => account.signMessage({ message }),
 });

components/Onboarding/init-xmtp-client.ts (1)

56-87: 🛠️ Refactor suggestion

Reduce code duplication and improve error handling

The initXmtpClientFromViemAccount function largely duplicates initXmtpClient. Consider refactoring to reduce duplication and improve error handling.

utils/passkeys/add-wallet-to-passkey.ts (1)

13-25: 🛠️ Refactor suggestion

Move API URL to environment configuration

The hardcoded API URL should be moved to environment configuration.

Add input validation for subOrgId

The function should validate the subOrgId parameter before proceeding with the wallet creation.

 export const addWalletToPasskey = async ({
   subOrgId,
   setStatusString,
 }: AddWalletToPasskeyParams) => {
+  if (!subOrgId?.trim()) {
+    throw new Error("Invalid subOrgId provided");
+  }
   setStatusString("Adding wallet to passkey. Creating Passkey Stamper...");

utils/passkeys/load-client-from-passkey.ts (3)

21-25: ⚠️ Potential issue

Critical: Replace hardcoded challenge with secure random value.

The hardcoded "TODO" challenge compromises the security of the passkey authentication process. A static challenge makes the system vulnerable to replay attacks.

---

27-30: ⚠️ Potential issue

Add input validation for passkey response.

The passkey response is used without validation, which could lead to security vulnerabilities.

---

44-47: 🛠️ Refactor suggestion

Enhance error handling to prevent information leakage.

The current error handling logs the entire error object, which might expose sensitive information.

screens/Onboarding/OnboardingPasskeyScreen.tsx (3)

71-97: 🛠️ Refactor suggestion

Prevent multiple simultaneous operations.

The loading state is shared across all operations which could lead to race conditions.

---

147-177: 🛠️ Refactor suggestion

Improve error handling in createXmtpClientFromAccount.

The error handling could be improved for better user experience and security.

---

248-253: ⚠️ Potential issue

Add input validation for passkey name.

The passkey name input lacks validation which could lead to security issues.

i18n/translations/en.ts (1)

55-60: ⚠️ Potential issue

Add missing error messages for passkey operations.

The passkey translations should include error messages for common failure scenarios.

Add these translations:

 passkey: {
   title: "Create Passkey",
   add_account_title: "Add account by passkey",
   subtitle: "Create a passkey to connect to Converse",
   createButton: "Create Passkey",
+  errors: {
+    creation_failed: "Failed to create passkey",
+    login_failed: "Failed to login with passkey",
+    invalid_name: "Invalid passkey name",
+    already_exists: "A passkey with this name already exists",
+  },
 },